Cross-table after (spec 0.5.0), a warning that suggests it, and integer keys 1..N, and release 1.16.0 - #49

Half the orders of the ecommerce example were placed before their customer
signed up. A table's creation column -- its first date or timestamp without
`after` named for the created stage (created_at, signup_date, start_date),
else its first named for no stage (order_date) -- is now kept on or after
the creation column of every parent row its foreign keys point at, through
a foreign key onto the parent's primary or unique key; with several
parents, after the latest. A date and a timestamp compare by day. Self
references, null foreign keys, parents without a date and foreign keys
that break a cycle are not followed.

The child keeps its own shape: a row dated before its parent takes another
parent created by then, drawn from the parents the column already points
at, so its date keeps the growth, seasonality and business hours it was
drawn with. Only a row with no such parent (or a one-to-one, which cannot
change parent) moves its date, drawn again from the column's day weights
and hours cut to the part of the window on or after the parent's, never
past as_of. Moving dates alone would have flattened the coffee webshop's
gift-season peak (3.1x May before, 0.6x after); taking older parents keeps
it (3.0-3.5x) at the cost of a steeper skew (top fifth of customers: 66%
of orders before, about 80% after).

A composite-key repair or a `when` fill that dates a row before its parent
afterwards moves only that row's date and places its later dates again.
On later days a new row whose parent was inserted the same day lands later
that day. `after_parent: false` on the creation column turns the rule off
for the table, and the generator rejects it anywhere else.

The late_arriving defect prefers rows that stay clear of their parents
once moved back, so it keeps breaking only the incremental model; a review
test moves to a seed whose late rows still show what it checks.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

With hint tests on, each foreign key a creation date follows writes
`model2data_not_before_parent` on the child's creation column: it joins
the child to the parent model through the foreign key and returns the rows
dated before the parent row, by day for a date against a timestamp. A key
several parent rows share counts its earliest, so a duplicate_keys defect
stays the unique test's to report. The macro ships in
macros/model2data_parent_tests.sql, written only when a project has such a
test, so other projects are what they were.

`hint_tests_for` takes the model's refs beside bare tables, and the defects
report checks the test the way its SQL reads, so a defect that dates a row
before its parent lists it in EXPECTED_FAILURES.md. A dbt run confirms the
test passes on clean data and fails on a customer created after its order.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

`after_parent` is new optional vocabulary, so by the spec's own rule it is
a minor version: allowed only in a document that says `model2data: 0.5.0`,
and an error naming the version to write in a 0.2, 0.3 or 0.4 document,
which otherwise read exactly as before. It is a boolean on the table's
creation column; anywhere else the reader names the column that is. A
writer keeps the version a document was read with and writes 0.5.0 once
it uses the hint; DBML with an `after_parent` note converts to 0.5.0.

The spec README says what 0.5.0 also says of every document's data, as a
minor release may before 1.0.0: a child's creation date is not before its
parents' (References), and a one-column integer primary key numbers the
rows 1..n in order (Keys). The schema's $id moves to /spec/0.5.0/,
PUBLISHING.md lists the 0.5.0 files of engine 1.15.0 beside the older
ones, and the guide pages name 0.5.0.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

The changelog's Unreleased section says what 1.15.0 changes and which
models generate different bytes for the same seed (every model with an
integer primary key; where the parent rule applies, its children too). The
README, LLMS.md and the time-shapes, distributions and dbt-project pages
describe the rule, the opt-out and the new dbt test. The determinism
digests are recorded again for these deliberate changes.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

A child's date no longer follows its parents' on its own, and the
`after_parent` opt-out is gone. Instead `after` names what a date follows:
a column of the same row as before, a parent's column as
`<table>.<column>`, or a list of either. `after: customers.created_at` on
orders.order_date keeps each order on or after the created_at of the
customer its foreign key points at.

The parent is reached through exactly one one-column foreign key onto
its key; validation names what is wrong otherwise (no such table or
column, not a date, no foreign key to it, only a composite one, one onto
a column that is no key, the column's own table, and two foreign keys to
the parent, named), and refuses tables whose afters name each other's
columns. The generator refuses a parent drawn after the child.

The technique that kept the stories stays: a late row takes an older
parent from those the column points at, and only a row with none (or a
one-to-one) moves its date within the column's own shape, never past
as_of. A list mixing the row's own columns places the value after both.
The fix-ups after `when` and composite-key repair, the later days, the
by-day comparison of a date with a timestamp, the dbt test
`model2data_not_before_parent` (one per parent column) and the
late_arriving preference all follow the hint now.

Validation warns where a child's first date can fall before a parent's
created_at-like date and no `after` names that parent, with the hint to
add as a structured `Issue.suggestion` (path, value, and the spec
version an older document needs) for a one-click fix. No warning for a
parent without such a date, a self-reference, or two foreign keys to one
parent.

A list or a parent's column in `after` is spec 0.5.0, gated as before.
The bundled examples (and the spec's coffee-webshop example) use it where
it is plainly right.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

The changelog's Unreleased section, the README, LLMS.md and the
time-shapes, distributions and dbt-project pages describe `after` naming
a parent's column, its errors and the warning that suggests it, in place
of the automatic rule. Dates change only for models that use it (the
examples now do); ids change for every model with an integer primary key.
The determinism digests are recorded again for these deliberate changes.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…o claude/parent-dates-and-ordered-ids

# Conflicts:
#	CHANGELOG.md

…ed PyPI

Co-Authored-By: Claude Opus 5.5 <[email protected]>